home *** CD-ROM | disk | FTP | other *** search
- REVISIONS FOR VERSION 1.1 OF EXC.EXE
-
- Many thanks to the few users who have reported problems and/or suggested
- enhancements. If you don't report them and I don't find them, they don't
- get fixed.
-
-
- 1. I apologize for the EXC.DOC file. In my rush to get it documented and
- uploaded, I neglected to spell check or proofread it. It was terrible.
- I hope it is much more readable now.
-
- 2. Leading and trailing TAB characters (hex 09) were not being removed from
- script lines, causing invalid command messages.
-
- 3. There appears to be a need in the user community to repeat commands,
- groups of commands and keys a known number of times to allow them to
- write smaller scripts.
-
- Added "ON n label". This is a powerfull loop control command similar
- to the logic used in FOR statements common in many programming languages.
-
- Added a repeat number that can be added to the end of a KEY command. The
- key that is specified will be repeated as many times as specified. For
- instance, "KEY <TAB> 5" stuffs five tabs into the keyboard buffer.
-
- 4. Fixed a problem where certain invalid key mnemonics were not generating
- error messages.
-
- 5. If you loop through SEARCH commands looking for multiple possible messages
- that could occur, each time the timer interrupt is invoked (18.2/sec) the
- entire screen is read, reformatted to remove attributes and searched for
- each SEARCH in the loop. WAITFOR and WAITSCR have built-in one second
- delays between screen reads to minimize this overhead.
-
- One solution is to stick a DELAY in the loop, but if you do this between
- each SEARCH, execution of the script will slow down dramatically.
-
- I added a READ command that will read the screen and do nothing else.
-
- I then added a LOOK command that searches the screen buffer that was last
- read by a READ, SEARCH, WAITFOR or WAITSCR command. It's just like the
- SEARCH command without reading the screen prior to the search.
-
- EXAMPLE 1: EXAMPLE 2: EXAMPLE 3:
-
- :Loop :Loop :Loop
- SEARCH "Continue?" READ SEARCH "Continue?"
- IFY Continue LOOK "Continue?" IFY Continue
- LOOK "ERROR:" IFY Continue LOOK "ERROR:"
- IFY Error LOOK "ERROR:" IFY Error
- GOTO Loop IFY Error DELAY 1
- :Continue DELAY 1 GOTO Loop
- . GOTO Loop :Continue
- . :Continue .
- :Error . .
- . . :Error
- . :Error .
- . .
- .
-
- In the above examples, Example 1 shows how you would have intuitavely
- coded the script in version 1.0. Adding a DELAY 1 at the end of the
- loop would have helped performance, but two screen reads would be per-
- formed each second. Example two demonstrates how READ and LOOK could
- be used to make a very efficient loop. Example 3 shows that, since
- a READ followed by a LOOK is equal to a SEARCH, so the third example
- is the best because it takes two iterations of the interrupt to process
- each command in the script. The first iteration reads and formats the
- command and the second executes it.
-
- 6. Installed COMMAND.COM as the default program name on the command line.
-
- 7. Modified QUIT and end0of-script logic to issue EXIT if COMMAND.COM was
- invoked.
-
-
- REVISIONS FOR VERSION 1.2 OF EXC.EXE
-
- Many thanks to the few users who have reported problems and/or suggested
- enhancements. If you don't report them and I don't find them, they don't
- get fixed.
-
- 1. Timeout processing was malfunctioning for WAITSCR. Fixed.
-
- 2. READ and LOOK were mistakenly included in v1.1 documentation, but are
- not actually implemented until v1.2.
-
- 3. In 1.1 and older, the maximum screen size was 80x50. EXC returned an
- error if you were in a larger screen mode. Also I had to obtain a 8,000
- byte buffer (character + attribute) to read the 80x50 screen regardless
- of the text mode you were using.
-
- I must preallocte the screen buffer because the spawned program may
- consume all remaining memory. I can't just use the current video
- settings since the spawned program may change the text mode.
-
- I have added a command "SCRMAX cols rows" that allows preallocation of
- buffers for large screen sizes. The default, if SCRMAX is not in the
- script, will be the rows and columns of the text mode in use when EXC is
- invoked. Please read the documentation under SCRMAX for full usage
- instructions and the implications and penalties involved in reserving
- large screen buffers.
-
- This prevents wasting memory in screen sizes smaller than 80x50 and
- allows EXC to fully function on screens larger than 80x50.
-
- Supported screen widths are from 40-200 columns. Supported screen
- heights are from 20-100 rows.
-
- 1. I no longer read the video attribute when I read the screen, thus
- cutting screen buffer requirements in half.
-
- 2. To minimize problems with spawned programs which may also be using
- timer interrupts, I have broken down the execution of many commands into
- parts executed in multiple timer interrupts.
-
- 3. For the same reason as for the previous changes, I have cut the time
- down for error beeps and for the delay the beeps. Errors, which emitted
- 4 beeps now only beep twice.
-
- 4. Timeouts, which emitted 3 beeps now emit no beep. If you need
- to know when a timeout occurred, place a beep in your script where
- needed. This is primarily because intentional timeouts could be quite
- common and don't require user attention.
-
- 5. Modified DELAY and TIMEOUT processing to compare against the system
- clock instead of using countdown timers via INT 1C. This gives more
- accurate timing since 1C may or may not be called 18.2 times per
- second, depending on how long the interrupt handler had it tied up.
-
- 6. I have added key combinations that will terminate (LEFT and RIGHT SHIFT
- keys)and pause/resume (SCROLL LOCK) the execution of scripts. Unlike
- pressing the PAUSE key, SCROLL LOCK pauses only script execution and not
- the spawned program. The PAUSE key will suspend both.
-
- 7. I have insterted code that detects pause state and suspends all delays
- until pause state is exited. For example, if you press the PAUSE key
- 5 seconds into a 10 second delay, when you press a key to resume
- processing, you will still have 5 seconds of delay before the next command
- is executed. No new commands will be initiated during pause state.
-
- 8. Fixed a problem that limited total memory allocations to 64k and sometimes
- caused system halt if more was requested for scripts, screen or spawned
- program.
-
- 9. Enhanced functionality and script debugging by adding the following 14
- new commands:
-
- TICK CLEAR PAUSE TIME
- WINMAX WINCOLS WINROWS CURSOR
- SHOWAT SHOW SHOWWIN LOCATE
- HIDEWIN TYPFILE
-
- 10. Rearranged the documentation so that commands are listed alphabetically.
- Added more examples. Added more in-depth explanations of operational
- considerations that might effect EXC's performance or lack thereof.
-
- 11. Included the script that I use for testing EXC in the distribution
- files. This provides at least one example of every command EXC
- recognizes.
-
- 12. Allow entry of quotes within a string by substituting \q for ".
-
-
- Version 2.0a
-
- The programs in version 2.0a are identical to those in version 2.0, except
- for the registration remider screen. The reminder screen and documentation
- have been updated to include instructions on how to register EXC online via
- CompuServe's SWREG section.
-
-
- REVISIONS FOR VERSION 2.1 OF EXC.EXE
-
-
- 1. Recompiled EXC in 8086/8088 code so that it could be used on XT class
- machines. Performance impact on 286 and above processors is negligible.
-
- 2. Added a parameter to the QUIT instruction. Normally on exit, EXC returns
- the return code of the executed program. If a number (0-255) is
- specified with the QUIT command, that value is returned as the DOS
- ERRORLEVEL return code instead of what was passed from the spawned
- program.
-
- An example of why you would want to set a return code:
-
- I use EXC to control PROCOMM PLUS to execute a script that synchro-
- nizes my clock with the Naval Observatory. I need to know if it
- fails.
-
- I can detect the error with my EXC script, but when I exit PCPLUS,
- PCPLUS always returns a return code of 255. Using the QUIT nn format,
- I can set a return code of 1 on error and 0 when there is no error.
-
- 3. After a PRTSC key mnemonic was executed, the script processor failed
- to continue to the next line and terminated at that point.
-
-
- REVISIONS FOR VERSION 2.2 OF EXC.EXE
-
- 1. Added support for using environment variables in any command string
- parameter.
-
- 2. When you tried to pass a parameter to the spawned program that
- contained spaces and was enclosed in quotes, the parameter arrived to
- the spawned program broken down into multiple one-word parameters. While
- EXC was passing it as a single parameter, DOS was breaking it down. I had
- to make sure each parameter passed to the spawned program was enveloped
- in quotes in order to assure proper operation.
-
- 3. EXC could have been copying one or more input parameters to uninitialized
- string pointers. This means that the parameters could have been copied
- anywhere in memory. These storage violations could cause random errors
- varying in degree of nastiness and symptioms. These pointers now point to
- a fixed array of allocated memory.
-
- If you experienced random, strange occurances after using EXC, this could
- be the cause. It could also cause QEMM exception 13 errors. I examine my
- code very closely for these nastiest of bugs, but with the flexibilty of
- data types, pointers and arrays used in C++, it is nearly impossible to find
- them until a repeatable error can be found.
-
- If you experience unusual problems after using EXC v2.2, try your best to
- repeat them. If you can in any way recreate the problem or narrow down the
- activity that causes the problem, let me know. EXC is becoming a very stable
- product now, thanks to your help. In this type of program it is impossible
- to test every combination that users will use.
-
-
- REVISIONS FOR VERSION 2.3 OF EXC.EXE
-
- Version 2.2 attempted to properly pass quoted parameters by enclosing all
- parameters in quotes. While this worked fine on Borland C and C++ programs,
- if the spawned program was PASCAL or assembler, it received the parameter with
- the quotes. Since most programmers were not expecting quoted parameters,
- they had no code to handle them. Borland C always remoed the quotes before
- a program could access the parameters. This means that EXC VERSION 2.2 DID
- NOT WORK WHEN MOST PASCAL AND ASSEMBLER PROGRAMS WERE INVOKED.
-
- I now check each parameter for a space, |, < or >. If it contains one of
- these, I assume the input string was quoted and pass it on with surrounding
- quotes. All other parameters are passed as-is.
-
- \" can no longer be used to imbed quotes in a parameter to be passed to a
- spawned program. \q must be used instead.
-
-
- REVISIONS FOR VERSION 2.4 OF EXC.EXE
-
- 1. Although EXC processed correctly, sometimes an erroneous warning message
- would appear at the end of the job stating that the script had failed to
- complete and claiming to have stopped at the last command in the script.
- The last command had, in fact, been executed.
-
- 2. Instead of assuming COMMAND.COM for the default when no spawned program
- is specified, I now use the program specified in the COMSPEC environment
- variable. If COMPSEC is not found in the environment, I then use
- COMMAND.COM.
-
-
-
- REVISIONS FOR VERSION 2.5 OF EXC.EXE
-
- 1. It appears that a few applications and at least one well known appli-
- cation development package actually write binary zeros to certain parts of
- screen memory. These appear as spaces on the screen but are actually read
- as binary zeros when EXC reads screen memory. When EXC is searching the
- video memory for a string, it uses a string search algorithm that is
- terminated at the first binary zero. This is because C++ uses binary
- zeros to terminate strings.
-
- The result is that certain string text would be displayed on the screen
- but would not be located by EXC because the search was terminated
- prematurely.
-
- EXC now replaces any binary zeros in the screen buffer text with spaces.
- This allows the search to perform as expected.
-
- 2. The ON function did not work properly when the counter was more than 9.
- This has been corrected.
-
-
- REVISIONS FOR VERSION 2.6 OF EXC.EXE
-
- The DELAY and TICK commands did not always work properly if the wait
- state was in effect at midnight when the system timer clock rolls over
- to zero. EXC has been modified to compensate for this possibility.
-
- Version 2.6a:
-
- We are moving. Updated registration screen and documentation to show
- new address. No functional changes.
-